Methods and systems for email integrated file delivery

ABSTRACT

Methods and systems consistent with the present invention provide a file delivery system for transmitting files to recipients using email, which may be used with existing email infrastructure. Email clients may “attach” files to an email by an attachment process. The attachment process, however, associates a placeholder with the email instead of the actual file. The placeholder is replaced with a URL link to the file and the email is sent. The system moves the attachments over the network to a remote server that is capable of delivering the attachments to the email recipients. File attachments are routed to recipients independent of the associated email.

FIELD OF INVENTION

The present invention relates generally to communications betweencomputer systems and, in particular, to methods and systems for emailand file delivery.

BACKGROUND OF THE INVENTION

As computer networks have developed into a means of structuring, sharingand transferring information, information systems such as electronicmail (email) have facilitated communication and information management.Users on a computer network generally use email to communicate privatemessages with each other. However, email has rapidly evolved into a newstandard communication medium moving beyond the typical memo frameworkto one of a universal tool for conducting business. The capability tosend any type of data attached as a file to an email message isincreasingly used not only for dissemination of information but as ameans of business collaboration. Thus, email attachments have become avital component of an organization's workflow.

Even after the last few years of the Internet revolution, which hasgenerated a multitude of collaboration software and services, emailstill accounts for 90-95% of all electronic collaborative activities inan enterprise.

Computer networks used by organizations typically comprise emailservers. The email server is a computer hardware platform whereapplication software responsible for receiving, transmitting, routingand archiving emails resides. Users of such a computer network typicallyhave client versions of an email application software for creating,sending, receiving and organizing emails installed on personalworkstations. The size of email attachments used for collaborationvaries considerably depending on the application. However, the trend istowards larger and larger files typically associated with rich mediaapplications, such as audio and video applications.

Another major constraint on the usage of attachments for collaborationin some email environments is the large amount of time it requires toattach large files in an email client, that is, the time from when auser chooses a file as an attachment to the point when the user is ableto activate the send button to send the email and attachment. In someemail clients, this takes a significant amount of time as the entireattachment is first retrieved from an archive, typically an internalstorage device such as a hard disk inside the personal workstation,before the control of the email application is returned back to theuser. Another major constraint is that the email client is frequentlytied up during the process of sending of emails with large attachments.

Furthermore, the volume of data passing through the email systems hasincreased beyond the capabilities of existing infrastructure of manycorporations resulting in strained bandwidth networks, unmanageablegrowth in distributed storage requirements and having an adverse impacton unrelated mission critical communications. Moreover, with the routingof large email attachments through existing email servers may come theassociated problems of excessive data loss or latency, excessive time toretrieve large files, and reliance on low technology alternatives torecover from failures and lack of effective and accurate reportingcapabilities. These problems can be compounded by strained IT resources,a need to extend the life of existing infrastructure, a desire toincrease the quality of other network services, a demand for an inherentfail-over mechanism for critical systems, or a requirement of accuratedata for forecasting and planning infrastructure growth and tracking ofresource utilization by business unit (i.e. department, partner, clientand geographic region or specific location) for subsequent charge back.

Conventional email file attachment delivery methods and systems are notefficient and difficult to manage, causing staff to lose preciousproductivity time transferring large files to compact disc (CD),printing hardcopy of the large files for sending by traditional courier,or using other ad-hoc manual tools such as the public File TransferProtocol (FTP) servers and file-sharing servers which are potentiallyvulnerable and do not address the issue of lifecycle management of theseoften sensitive files.

The negative impact on operational productivity and the relatedinfrastructure has generated a compelling need for a solution that meetsboth business and technical requirements. One such requirement, from theperspective of an enterprise, is to provide a solution that supports thetools employees are most familiar with, so as to maintain the existingbusiness process and workflow.

SUMMARY OF THE INVENTION

Email distribution methods and systems consistent with the presentinvention are described herein for providing a seamless, enterprise-widefile delivery solution for enabling collaboration through large emailattachments by providing a framework for their file attachment, storage,transport, access and lifecycle.

In accordance with one embodiment of the invention, there is disclosed amethod for delivering a data file as an email attachment in a computersystem having an email server, a hosting server and a client computer indata communication with the email server and the hosting serverconsistent with the present invention may comprise composing an emailhaving a message portion using an email client application running onthe client computer, the email having a source system and a destinationsystem being associated thereto. The method may further compriseinitiating an attachment routine for attaching a data file to the emailand generating a placeholder for associating the data file selected by auser to the email for including into the message portion of the email inresponse to the attachment routine being activated and identifying thedata file for attaching to the email. The data file indicated by theplaceholder may be retrieved and delivered to the hosting server. Theemail is delivered to the email server upon the data file beingtransferred to the hosting server.

In accordance with another embodiment of the invention, there isdisclosed an email distribution system for delivering a data file as anemail attachment, the system comprising means for composing an emailhaving a message portion using an email client application running on aclient computer, the email having a source system and a destinationsystem being associated thereto; means for initiating an attachmentroutine for attaching a data file to the email; means for generating aplaceholder for associating the data file selected by a user to theemail for including into the message portion of the email in response tothe attachment routine being activated and identifying the data file forattaching to the email; means for retrieving the data file indicated bythe placeholder; means for delivering the data file to a hosting server;and means for delivering the email to a email server upon the data filebeing transferred to the hosting server.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification exemplify certain aspects of the presentinvention and, together with the description, serve to explain some ofthe principles associated with the invention.

FIG. 1 shows a simplified prior art block diagram of a typical networkof email servers and email clients and the data flow therein;

FIG. 2 shows a block diagram of a network of email servers, emailclients and hosting servers and the data flow therein in accordance withan embodiment of the invention;

FIG. 3 shows a process flow diagram of a placeholder-inserting taskaccording to at least one embodiment of the invention;

FIG. 4 shows a process flow of an email sending initiating taskaccording to at least one embodiment of the invention;

FIG. 5 shows a process flow of a background email processing taskaccording to at least one embodiment of the invention;

FIG. 6 shows a process flow of a file-uploading task according to atleast one embodiment of the invention; and

FIGS. 7, 8 and 9 show an exemplary transaction consistent with thepresent invention.

DETAILED DESCRIPTION OF THE INVENTION

An email distribution system for providing seamless enterprise widemessage and data file delivery for enabling business collaboration isdescribed hereinafter. Embodiments of the invention are described withreference to the figures of the drawings, wherein like elements areidentified with like reference numerals.

Certain embodiments of the present invention enable an email sender toattach large files from the familiar email interface quickly andefficiently by modifying the process of attaching based on policies thatare driven by configurable parameters. For example, in one embodiment,only attachments that meet a threshold size would be attached using thismechanism. The attachment process is swift as the time consuming processof attaching the file to the email is bypassed and all furtherprocessing is shadowed for background operation. The attachment processinserts a placeholder in the email instead of the attachment and, whenthe user sends the email, these attachments may be further encapsulatedinside larger units referred to as “packages.” These packages may besubsequently transferred to a server capable of communicating on any oneof a set of protocols through an integrated transport system.

The principles of the present invention may be used with existingprotocols and methods for large file transfer. In certain embodiments ofthe present invention, the transfer can be optionally governed byconfigurable parameters such as, but not limited to, the uploaddestination, transport protocols, minimum allowable transfer rates andtime-outs and upload caches. Examples of the transport protocols areHTTP, HTTPs, FTP and UDP based transports. However, the system is notlimited to these transport protocols and can use any method of transportavailable on a computer network. Among other criteria, the protocols canbe chosen based on security and performance needs of the Enterprise.

After the successful transfer, an email processing module replaces theplaceholders with embedded links (URLs) which can be used to retrievethe attachment from the Internet or Intranet and then sends the email tothe intended recipients. Since, in certain embodiments, the attachmentsand email are sent by the email processing module in the background, theuser perception of the sending process is comparable to sending an emailwithout any attachments, regardless of the size and number of theattachments associated with the email.

While the attachment is processed in the background, the email may bemoved to a pending folder where it is held until the attachment isprocessed. When the email arrives at the recipient, the attachment isavailable for download, similar to how email works today. Whileattachments are being packaged and transferred, the user can continuewith other tasks in the email client.

Each set of attachments of an email may be treated as a “package.” Alongwith the attachments, each package may optionally contain a meta-filethat encapsulates meta information regarding the package itself. Forexample, this information may comprise the sender's email, recipients,list of attachments as well as its attributes such as size and type. Itcan also comprise various attributes of the email such as return receiptand has the provision for associating job codes with each attachment.The job codes allow for attachment tracking as well as enabling costs tobe charged back to financial systems. This is analogous to present dayshipping of physical packages for which a tracking identification isused as well as charged back to department accounting.

Thus, certain embodiments of the present invention enable seamless usageof existing email workflow for collaboration on large files withoutdisrupting or impacting other applications and services. Furthermore,certain embodiments may allow for policy-based management of attachmentsthrough the use of optional parameters like attachment size. Certainembodiments of the present invention also provide recipientauthentication based on enterprise directory standards like LightweightDirectory Access Protocol (LDAP) to prevent attachment forwarding,delivery confirmation to allow the sender of emails to be notified whenthe recipients download their email attachments and automated backgroundreplication of attachments to three recipients' preferred remoteservers. Another option is for securing previously non-secured method ofcollaboration via email attachments.

Existing email distribution networks such as the email distributionnetwork 100 shown in FIG. 1, comprise email servers 102A and 102B andemail clients 104A, 104B, 106A and 106B that are typically located atdifferent geographical locations within an enterprise. The email servers102A and 102B and the email clients 104A, 104B, 106A and 106B areelectronically interconnected by communication links 108A-108E as seenin FIG. 1. When a user sends an email with or without a data fileattachment (attachment) to a recipient, the email traverses thecommunication links from the sending email client to the recipient emailclient. For example, when email client 104B (sender) sends an email 110containing a message portion 112 and an attachment portion 114 to emailclient 106A (recipient), the email 110 traverses communication link 108Bto the email server 102A. The email server 102A then forwards the email110 to the email server 102B via the communication link 108C. Finally,the email server 102B forwards the email 110 to the recipient via thecommunication link 108D. Existing email distribution networks deliveremails and the attachments together. As such, these existing networksare more suited for delivering emails without any attachment or withattachments that are small in size. For emails with large sizeattachment or many attachments, existing email distribution networkspresent a number of limitations. As described in the foregoing, some ofthese limitations include the lengthy period required by the emailclients to retrieve and attach large files, the email and the largeattachment have to traverse a tortuous and inefficient route over thecommunication links of the network of email servers to reach therecipients and in the process consume valuable resources such as storagespace, delivery time and network bandwidth.

The email distribution system according to an embodiment of theinvention for efficiently delivering emails with large attachmentincludes an email distribution network 200 as shown in FIG. 2 and thevarious modules as described hereinafter. The email distribution network200 makes use of existing email distribution networks with the additionof at least one hosting server. As an example, the email distributionnetwork 200 comprises email servers 102A and 102B, email clients 104A,104B, 106A and 106B, hosting servers 204 and 206 and communication links108A-108E and 202A-202C. The email servers 102A and 102B and the emailclients 104A, 104B, 106A and 106B are electronically interconnected bythe communication links 108A-108E which is the existing emaildistribution network 100 as shown in FIG. 1. The hosting server 204 iselectronically connected to the email clients 104B and 106A via thecommunication links 202A and 210, respectively. Similarly, the hostingserver 206 is electronically connected to the email clients 104A and106A via the communication links 208 and 202C, respectively. The hostingservers 204 and 206 are further electronically interconnected by thecommunication link 202B for transferring data therebetween. In theexemplary embodiment shown in FIG. 2, the communication links 208 and210 are shown as dotted lines to indicate that the communication linksare not in use. Further, the solid lines with arrows merely indicate thedata flow in at least one embodiment of the invention. In practice,these communication links may be bi-directional.

According to an embodiment of the invention, when a user at the emailclient 104B wishes to send an email with a data file attachment(attachment) to a recipient at the email client 106A, the email and theattachment are delivered separately. The data flows and the sequence ofsteps carried out by the sending email client 104B for sending the emailand the attachment, and the receiving steps carried out by the receivingemail client 106A, are described hereinafter.

Typically, email clients are provided with an email client applicationrunning on the email client machine. The email client application allowsa user to compose messages and send the messages as an email 110, asshown in FIG. 1, with or without an attachment to a recipient connectedto the email distribution network. The email 110 contains a messageportion 112 and an attachment portion 114, if any. In at least oneembodiment, the existing email client application is augmented toprovide extra functionality for providing an efficient method fordelivering email with large attachment efficiently to the desiredrecipient(s). The augmentation may involve, for example, providing afile-attaching module, a background email processing module and/or afile-uploading module for integrating into the existing email clientapplication. The file-attaching, background email processing, andfile-uploading modules may be software programs that may be embeddedinto an existing email client application to provide an augmented emailclient application, hereinafter referred to as the email clientapplication. However, it is obvious to one skilled in the art that thesemodules, namely the background email processing and the file-uploadingmodules can function independently from the existing email clientapplication. As such, these modules do not have to be integrated intothe existing email client application.

In addition to the existing attach button commonly found in existingemail client applications, the email client application is provided witha second attach button for allowing the user to attach data files to theemail in an efficient way. As such, the second attach button worksdifferently from the existing attach button as described hereinafter.

File-Attaching Module

The file-attaching module is activated in response to events triggeredby a user pressing the second attach button or the send button in theemail client application. The file-attaching module comprises two tasks.The first task is a placeholder-inserting task 300 as shown in FIG. 3.The placeholder-inserting task is activated in response to the userpressing the second attach button. The second task is an email sendinginitiating task 400 as shown in FIG. 4. The email sending initiatingtask is activated in response to the user pressing the send button.

Second Attach Button

When the user presses the second attach button at a step 302, theplaceholder-inserting task 300 is activated. Like in conventionalprograms, the user may be prompted to select an attachment to beattached to an email. Once the user has selected the attachment, theattachment size may be compared against a configurable preset thresholdin a step 304. If the attachment size is equal to or smaller than thepreset threshold, a placeholder is inserted into the email instead ofthe actual attachment. The placeholder may be a pointer pointing to theactual attachment the user selected or some equivalent data associatedwith the selected file. In some conventional email client applications,the file attaching procedure retrieves the attachment immediately afterthe user selects the attachment. If the attachment is large, theretrieval time is undesirably long and the user has to wait for theretrieval to finish. In at least one embodiment of the presentinvention, the time required to insert a placeholder into an email issubstantially shorter regardless of how large the attachment is. Thus,the user quickly gains control of the email client application. Further,the placeholder can be easily removed should the user change his or hermind before sending the email. However, if in the step 304, theattachment size is smaller then a preset threshold, the attachment maybe retrieved and attached to the email using conventional measures in astep 308. In certain embodiments of the present invention, placeholdersmay be used regardless of file size.

The placeholder-inserting task 300 can also comprise a prompt to allowthe user to enter job code or project identification information forassociation with the attachment selected by the user. The job code can,for example, be an alphanumeric tag that is used to associate theattachment with a corresponding project identification for accountingcharge back purposes. The job code and project identification associatedwith the attachment can be used to track resource usage and subsequentclient charge back for the bandwidth and storage cost associated withthe transfer and lifetime of the attachment (i.e. the length of time theattachment is retained by the hosting server before it is deleted).

Certain embodiments of the present invention allow encryption of theattachment. For example, when the user selects the option, the user mayalso indicate that the file should be encrypted. In other cases, whenthe user selects a file, a parameter may be written in the placeholderto indicate that the attachment is to be encrypted. Files may beencrypted using any one or more conventional encryption methods, such asBlowFish or PGP. The sender may also provide the recipient with themeans to decrypt the attachment via a separate email or through anyother medium.

Send Button

When the user presses a send button at a step 402, as shown in FIG. 4,the email sending initiating task 400 is activated. The task 400proceeds to check the email for placeholders in a step 404. If aplaceholder is found, the email may be moved to a pending folder forfurther processing by the background email processing module in a step406. However, if no placeholder is found in the email at the step 404,the email may be delivered in accordance with the existing procedure ina step 408. In the existing procedure, the email may be sent directly tothe email server 102A without further processing at the email client104B machine. Once a copy of the email is sent to the email server 102A,for example, the email may be moved to the sent folder after which thecontrol of the email client application is released back to the user. Inthe step 406, once the email with the placeholder is moved to thepending folder, the control of the email client application may beimmediately returned to the user. Thus, the user does not have to waitfor the email to be sent, which can be time consuming if the attachmentis large.

Background Email Processing Module

The background email processing module operates in the background of theemail client application carrying out a background email processing(BEP) task 500 as shown in FIG. 5. The background email processingmodule may be activated when the user launches the email clientapplication.

Once activated, the BEP task 500 scans the pending folder for emails toprocess at a step 502. If a new email is found in the pending folder ina step 504, the attachment pointed to by the placeholder may beencapsulated as a package and copied into a package processing directoryin a step 506. Additionally, if the placeholder indicates that theattachment is to be encrypted, the BEP task 500 will then encrypt theattachment as well. The BEP task 500 then may extract meta-informationfrom the email and the sender profile that may be residing in the emailserver 102A and may compile the meta-information to provide a meta-filein a step 508. Meta-information extracted from the email may comprise,for example, the sender email address, recipient list, names ofattachments and job code associating with the attachments. The BEP task500 then may store the meta-file in the package processing directory inthe email client 104B machine for further processing by thefile-uploading module and reverts back to the step 502.

However, if no new email is found in the pending folder in the step 504,the BEP task 500 proceeds to a step 514 to check for any completed jobperformed by the file-uploading module. When the file-uploading modulehas completed uploading the attachment 214 and the meta-file, thepackage processing directory may be renamed to indicate, for example,that the attachment 214 is successfully uploaded to the hosting server204.

Detailed description of an exemplary file-uploading module and itsfunctions are provided hereinafter. If no completed job is found in astep 516, the BEP task 500 reverts back to the step 502. However, if acompleted job is found, the BEP task 500 proceeds to a step 514. In thestep 514, the placeholder in the email is replaced by a correspondinglink to form an email package 208 having a message portion 210 and alink portion 212. The corresponding link indicates where the attachmentpointed to by the placeholder is being stored. The corresponding linkmay be provided by the file-uploading module and may be, for example, auniform resource locator (URL), a uniform resource identifier (URI), ora uniform resource name (URN). Each placeholder may have a uniquecorresponding link. Thus, if the email has two placeholders (indicatingthat the user has selected two data files to be attached with theemail), two separate corresponding links are provided. The linkoptionally contains other information gathered from the meta-fileembedded in it like the job code associated with the attachment and ifthe email sender requested for a download confirmation and the likeverification functions.

After replacing the placeholder with the corresponding link in the step514, a copy of the email package 208 is sent to the email server 102A ina step 516 via the communication link 108B. The BEP task 500 then movesthe email package 208 to the sent folder in accordance with the existingprocedure in a step 518 and reverts back to the step 502. Thus, the BEPtask 500 ensures that at or near the time the recipient at the emailclient 106A receives the email package 208, the attachment 214 is readyfor downloading from the location pointed to by the corresponding link212.

The BEP task 500 may be terminated when the user terminates the emailclient application. However, when the user terminates the email clientapplication and the BEP task 500 is in the middle of processing anemail, the user can be prompted to confirm if he or she wants toterminate the email client application. If the user confirms thetermination of the email client application, an automatic resumption ofthe email processing by the BEP task 500 can be included in the BEP taskthe next time the email client application is launched. The BEP task 500can be modified to provide a termination preventing feature that preventthe user from terminating the email client application until a criticalprocessing is finished. For example, the email client application may beprevented from being terminated when the BEP task 500 is busy processingan urgent email.

Further, the BEP task 500 can be modified to provide an email sendingcancellation process for canceling an email in the pending folder. Theemail sending cancellation process may allow the user to select an emailresiding in the pending folder and instruct the BEP task 500 to refrainfrom processing the email. The email can then be deleted, modified, orsaved for sending at a later time.

Certain embodiments of the present invention support the dynamicapplication of any changes in the configurable parameters. For example,the FU task 600 may poll the hosting server 204 for any changes inconfigurable parameters such as the location list to be used foruploading the attachment 214, the threshold for attachment size thatwill operate for special attaching for the email clients 104(A-B) and106 (A-B), the time for which the links inserted in the email will ceaseto be valid after insertion, whether automated notification by email tothe sender on the successful download of the attachments is enabled ornot, whether recipient authentication feature (i.e. the ability toconfigure whether or not a recipient must enter a password beforedownloading an attachment) is enabled or not, and the like verifyingfunctions. Any changes made by the administrator at the hosting server204 may thus applied in a dynamic manner without restarting the emailclient application. Subsequent emails may be processed using the updatedparameters automatically without the user being aware of any changes inthe application behavior or policies.

File-Uploading Module

In certain embodiments consistent with the present invention, thefile-uploading module is an integrated transport system, capable ofleveraging several protocols and methods for large file transfer againaccording to specific parameters, for example, the transport protocol tobe used. The file-uploading module can communicate with the hostingserver 204 on any one of the protocols supported by the hosting server204 using the HTTP, HTTPS, FTP or the like file transfer protocolssupported by the email server 102A and hosting server 204. The filetransfer protocol may be chosen based on the requirements of the filetransfer situation. For example, HTTP or FTP may be the best option forefficient file transfer and HTTPS may be best for secure file transferover the Internet.

In certain embodiments of the present invention, the efficiency of thefile-uploading module may by improved by use of parallel processing.Parallel processing may be enabled by, for example, configuring multiplenetwork connections to use multiple HTTPS tunnels for uploading multipleattachments to specified hosting servers. The number of HTTPS tunnelsmay be determined by balancing system performance against systemresource utilization, for example, bandwidth, CPU and memory availableon the hosting servers.

To further improve efficiency of uploading the attachment 214, certainembodiments of the present invention may employ technologies todetermine if attachment 214 has already been uploaded. For example, byusing technologies like MD5, certain embodiments of the presentinvention may hash the file contents of attachment 214 and compare thehash value with the hash value of files previously uploaded to thehosting server 204 using the same path. This feature may result in ansignificant gain in bandwidth and storage as the attachment 214 will notbe uploaded again if the file-uploading module is able to detect thatthe attachment 214 already exists on the hosting server 204.

In certain embodiments, the file-uploading module is activated when theuser launches the email client application. Like the background emailprocessing module, the file-uploading module may operate in thebackground, carrying out a file-uploading (FU) task 600 as shown in FIG.6. The FU task 600 is responsible for efficiently delivering theattachment 214 provided by the BEP task 500 to a pre-specified remotehosting server. A detailed description of the FU task 600 according toat least one embodiment of the invention is provided hereinafter.

Upon finding the attachment 214 in the package processing directory, theFU task 600 may be initiated to upload the attachment 214 to the hostingserver 204. In a step 602, the hosting server 204 may be polled toestablish communication with the FU task 600. In the step 602, thehosting server 204 may also be polled for any updates to any of theconfigurable parameters that may control the operation of the BEP task500 and FU task 600.

In step 604, the hosting server 204 may also check for readiness todeliver the attachment 214 thereto. If the hosting server 204 is notready, the FU task 600 proceeds to a step 606 where a next hostingserver is selected. However, if the hosting server 204 is ready, theattachment 214 (which may be encapsulated as a package) in the packageprocessing directory may be retrieved and uploaded to the hosting server204 in a step 608. If the package is larger than a preset threshold, thepackage may be split into small parts in the step 608. These small partsmay be recombined at the hosting server 204 to form the packagecontaining the attachment 214. This feature provides certain embodimentsof the present invention with the capability to resume interrupteduploads by only uploading the parts of the attachment 214 that cannot beuploaded due to a bad or broken connection which may enhance the overallefficiency of the email distribution network 200.

In certain embodiments, the user may attach more than one attachment tothe email. In this embodiment, the FU task 600 continues to retrieve andsend all the attachments until the meta-file is found. Once themeta-file is found, it means that the BEP task 500 has finished copyingthe attachments to the package processing directory. In the step 608,once the attachment 214 is successfully uploaded, the meta-file isuploaded, signaling to the hosting server 204 the end of the uploadingsession.

In a step 610, a check may be carried out to verify if the attachment214 and the meta-file are successful delivered to the hosting server204. If the uploading is unsuccessful, the FU task 600 proceeds to astep 612 where the uploading error is reported before proceeding to thestep 606 to select an alternative hosting server to upload to.

If the attachment uploading is successful in the step 610, the FU task600 may generate a locator code in a step 614. The locator code may be,for example, a secured uniform resource locator (secured URL). Thelocator code may be stored onto a database and associated with theattachment 214. Once the locator code is generated, a locator object maybe generated from the locator code. The locator object is typicallyreferred to as a link for embedding into an email. In at least oneembodiment, the BEP task 500 uses the locator object to replace theplaceholder in the step 514.

The locator object may be generated dynamically and can encompasssecurity features to prevent unauthorized access to the attachment 214.The security features may comprise cryptographic tokens, shared keys andother authentication mechanisms. For example, the locator object may usea shared key as a means for authentication on a remote storage serverand a 128-bit encryption for secured delivery of the attachment 214. Thesecurity features can further comprise an expiry date and time. Theexpiry date and time establishes the life of the locator object,subsequent to which the attachment 214 may not be downloadable from aserver storing the attachment 214. Other security features can alsocomprise components to specify whether the recipient should be verifiedbefore downloading the attachment 214, thus preventing attachmentforwarding and if a download confirmation email should be sent to thesender once the attachment 214 is successfully downloaded by therecipient. The locator object can optionally contain other informationlike the job code associated with the attachment pointed to by it.

Once the locator object is generated, the locator object may be writteninto the meta-file (for use by the BEP task 500), and the packageprocessing directory may be renamed to indicate that attachment 214 issuccessfully uploaded. The FU task 600 then proceeds to a step 616 tolog the results of the delivery and terminates.

The FU task 600 can also comprise a capability to support an optionaluser interface that can be used to view the attachment uploadingprogress for feedback to the user.

Hosting Server

The hosting servers 204 and 206 provide a remote file system likefunctionality wherein it is possible to upload, retrieve and get alisting of files besides allowing optional operations like move ordelete on a search result set. Examples of the hosting servers 204 and206 are HTTP servers, FTP servers and servers that support protocolsthat are capable of storing and delivering files.

In addition to providing file system like functionality in a secure,fast and reliable manner, the hosting servers 204 and 206 may alsoprovide user registration and authentication features by maintaining auser database. Parameters contained in the meta-file uploaded by thefile-uploading task can be used by the hosting servers 204 and 206 tocontrol policies for storage, replication, transport, access, andlifecycle management. The meta-information in the meta-file can comprisesender, recipient list, email server profile for internal recipients,including department and location, file name and extension and job codeor project identification associated with the file attached. The hostingserver (i.e. hosting server 204) that receives the attachment canreplicate the uploaded attachments to the preferred server(s) of all therecipient(s) with their profiles exist either in the enterprise'sdirectory server or in the registered user database immediately afterthe upload thus ensuring minimum download time for each recipient. Thejob code associated with each attachment in the meta-file is stored bythe hosting server 204 and can be mined to generate usage reports forcharging back costs.

The secure link inserted in the email can be clicked by the recipient toretrieve the attachment pointed to by the link either directly withoutauthentication or after being password authenticated depending on theconfiguration set. This configuration may be done either at the hostingservers 204 and 206 or may be encapsulated as a component in the linkitself.

If recipient authentication is required, the authentication can be doneby querying pre-determined directory server(s) like the lightweightdirectory access protocol (LDAP) server belonging to the enterprise orby searching in the registered user database stored in the hostingservers 204 and 206. The recipient can be asked to enter his emailaddress that can be further verified against the original recipient listfor the email from the meta-file if so desired. The user can also berequired to enter a password, which may be verified by the hostingserver from which the attachment is downloaded from either the directoryserver or the user database. Thus, providing a framework for verifyingthe recipient before download so that only the intended recipients areallowed to download the attachment. In this way, forwarding theattachment to non-approved recipients is prohibited for attachmentcontainment purposes. This can be useful in the case where the materialsent in the attachment is sensitive and requires protection.

In case where the recipient is not found in the directory server or theuser database, a new user profile can be created by having the recipientsubmitting a password and preferred location for future deliveries. Ifthe email address is not found in the recipient list or the password isincorrect then the download can be disallowed; otherwise the downloadlink can be authenticated for validity by the hosting server.

Therefore, the hosting servers 204 and 206 can be configured to disabledownload by any recipient not on the original mailing list via emailforwarding in addition to the authentication mechanism for file deliverydescribed in the foregoing.

Further, if the sender requests for a return receipt using the existingemail client application feature, the hosting server can send a downloadconfirmation email to the sender after the attachment is successfuldownloaded by the intended recipient(s).

File lifecycle management can be controlled by parameters and can beglobally enforced, or enforced on a file or hosting server specificbasis. This policy can be driven by frequency of access or timeframe.For example, the hosting server could be configured so that theattachment is deleted after all recipients have downloaded the file, orsimply after two weeks regardless of the number of access.

Administration and Reporting

Further features such as administration and reporting can be providedfor the hosting servers 204 and 206. The administration feature mayinvolve, for example, setting up and modifying the various parametersthat decide the policies governing the functioning of the hostingservers 204 and 206 and the email clients 104 (A-B) and 106 (A-B). Thiscan be done by an administrator manually or through an interface to thehosting servers from a different location. The administrator can set orchange the primary and secondary location to be used for uploading theattachments. The administrator can set or change the threshold forattachment size that will operate for special attaching for the emailclients. Further, the administrator can set or change the time for whichthe links inserted in the email will cease to be valid after insertion.The administrator can enable or disable automated notification by emailto the sender on the successful download of the attachments. Theadministrator can enable or disable the recipient authentication feature(i.e. the ability to configure whether or not a recipient must enter apassword before downloading an attachment).

The hosting servers 204 and 206 can also provide a list of theregistered email recipients, addition of new email recipient profiles tothe database and setting or changing the recipient profile informationsuch as password and attachment download location preference. Forexample, administrators can view senders who have used the emaildistribution network 200 and the details of the attachments sent by thesenders. The logs uploaded by the file-uploading task and theinformation maintained by the hosting servers 204 and 206 can be used tocreate reports at the file level to provide a comprehensiveunderstanding of attachment resources, the availability, usage and costof the attachment resources. The same can be done by any event capturingsoftware in place of the logs at the hosting servers 204 and 206.Another word, it is the capturing and processing of events that allowsuch reports to be created. Thus, the attachment uploading eventcaptured in the logs can be used to generate access statistics detailson a per sender basis. The resources (i.e. bandwidth and storage) usedcan be quantified to track and control expense as well as monitorbusiness practices on a hosting server basis as well as per senderbasis.

The logs can be used to create reports that help track individualattachments by date, recipient user identification, file size and timeof the attachment download.

Job codes and project identifications in the meta-files can be used togenerate reports on resource utilization by account which enable thecapture and attribute costs to partners and vendors and facilitate theassigning of profit and lost statement ownership of IT related costs tothe relevant departments.

Exemplary Embodiment

To further illustrate at least one embodiment of the invention, oneexample of sending and receiving an email with a large size attachmentis provided hereinafter. In this example, John, an employee of ACMEcorporation in California sends an email with large size attachment tofour recipients namely Annette, a co-worker in Paris, France, Ms. Asakoand Mr. Taka who work for Great Production House in Tokyo, Japan andPaul, an employee of Acme Printers, Taiwan.

FIG. 7 shows the sequence of events triggered when John 705 sends outthe email. John 705 is able to attach the large file (attachment) 702and send the email 704 immediately using the email interface componentof the file-attaching module that bypasses the normal attachment processby inserting a placeholder and the sending process by moving the emailto a pending folder. Thereafter, the background email processing taskcopies the attachment 702 and a meta-file (for containing the senderemail address, recipient list, names of attachments and job codeassociating with the attachments) into the package processing directory.When the file-uploading task detects the attachment 702 in the packageprocessing directory, it sends the attachment 702 and the meta-file tothe California Hosting Server 706. After detecting the successfultransfer, the background email processing task replaces the placeholderwith a secure URL and sends the email 704 with the secure link to theCalifornia eMail Server 708 in the ACME corporate network from where theemail is sent onwards to all the recipients.

FIG. 8 depicts the optional automated process of replication of fileattachments for optimizing the delivery to registered recipients. In theexample, assuming that Annette in Paris 715 and Asako in Tokyo 715 haveused the system for receiving email attachments before. Thus, Annettehas a profile on the ACME's lightweight directory access protocol (LDAP)server 802 while Asako is registered with a recipient profile on thesystem. As soon as the California hosting server 706 receives theattachment 702, it checks the meta-file to see if any of the recipientsare registered with its user database 804 or are part of the ACME's LDAPdirectory. The attachment 702 is scheduled for replication in thebackground to the preferred location for Annette (i.e. the Francehosting server 806) and for Asako (i.e. the Japan hosting server 808).Since Taka in Tokyo 715 and Paul in Taiwan 720 are not registered yet,no further action is required for the time being.

The delivery of the email 704 and the attachment 702 to the recipientsin Paris 710 and Tokyo 715 is shown in FIG. 9 after all the fourrecipients get the same email with the secure link. When Annette clickson the link in the email, the attachment 702 is immediately downloadedfrom the France hosting server 806 and no further user action isrequired. Similarly, when Asako 715A clicks on the link in the email,the attachment 702 is immediately downloaded from the Japan hostingserver 808. However, when Taka 715B clicks on the same link, a web page902 is launched, which prompts him to register his profile by enteringhis email address, password and a preferred location for futurereplication, which he can select from a list provided. Taka 715B is thenable to select that he too wants to download from the Japan hostingserver 808 and since the attachment 702 is already replicated there forAsako 715A, Taka 715B also downloads the attachment 702 from the Japanhosting server 808. Thus, one copy of the attachment 702 at the Japanhosting server 808 is enough for serving the requirements of allrecipients who identified the Japan hosting server 808 as theirpreferred location.

FIG. 9 also depicts the process of attachment delivery to Paul in Taiwan720. In the example, Paul is also not registered and upon clicking onthe link, he is prompted to register himself (via a web page 904) in thesame manner as Taka 715B in Tokyo. Paul selects the closest location,which is the Japan hosting server 808 and is able to seamlessly downloadthe attachment 702 after the registration process. Furthermore, futurereplication and delivery for Paul will be based on his specific profile,which identifies the Japan hosting server 808 as his preferred location.

1-20. (canceled)
 21. A method comprising: transferring, from a firstclient device, at least one data file to a server to be stored by astorage device communicatively coupled to the server; generating anotification for sharing of the at least one data file, wherein thegenerated notification includes a placeholder; replacing the placeholderin the generated notification with a link to retrieve the at least onedata file from the storage device communicatively coupled to the server;transmitting, by the server, the notification with the link to a secondclient device to retrieve the at least one data file from the storagedevice communicatively coupled to the server; and retrieving, by thesecond client device, the at least one data file from the storage devicecommunicatively coupled to the server based on the received link in thenotification.
 22. The method of claim 21, further comprising:authenticating, by the server, a first user of the first client device.23. The method of claim 22, further comprising: authorizing, by theserver, the first user of the first client device to provide at leastone data file to the server to be shared.
 24. The method of claim 21,further comprising: authenticating, by the server, a second userassociated with the second client device.
 25. The method of claim 24,further comprising: authorizing, by the server, the second user of thesecond client device to receive the notification including the link. 26.The method of claim 21, further comprising: generating, at the server,the placeholder when a size of the at least one data file to be sharedis larger than a preset size.
 27. The method of claim 21, furthercomprising: generating, at the server, metadata that is descriptive ofthe notification and the at least one data file; and generating, at theserver, a meta-file based on the generated metadata, wherein themeta-file includes the at least one data file and the metadata.
 28. Themethod of claim 27, further comprising: assigning, at the server, aunique identifier to the meta-file, wherein the unique identifier isassociated with the at least one data file for tracking purposes. 29.The method of claim 27, wherein the metadata includes information tocontrol, by the server, at least one from the group consisting of:replication, transmission, access, and lifecycle management of the atleast one data file.
 30. The method of claim 21, wherein the retrievingfurther comprising: receiving, by the second client device, thenotification including the link; receiving, by the second client device,a selection of the link; locating, at the storage device communicativelycoupled to the server, the at least one data file corresponding to thereceived link; and transmitting, at the server, the located at least onedata file to the second client device.
 31. The method of claim 30,further comprising: receiving, at the server, an authorization key fromthe second client device; and transmitting, at the server, the locatedat least one data file to the second client device based on the receiptof the authorization key.
 32. A system comprising: a server that iscommunicatively coupled to a storage device; and a first client deviceand a second client device, wherein the first client device transfers atleast one data file to the server to be stored by the storage devicethat is communicatively coupled to the server, wherein the servergenerates a notification for sharing of the at least one data file, withthe generated notification including a placeholder, replaces theplaceholder in the generated notification with a link to retrieve the atleast one data file from the storage device communicatively coupled tothe server, and transmits the notification with the link to the secondclient device to retrieve the at least one data file from the storagedevice communicatively coupled to the server, and wherein the secondclient device retrieves the at least one data file from the storagedevice communicatively coupled to the server based on the received linkin the notification.
 33. The system of claim 32, wherein the serverauthenticates a first user of the first client device.
 34. The system ofclaim 33, wherein the server authorizes the first user of the firstclient device to provide at least one data file to the server to beshared.
 35. The system of claim 32, wherein the server authenticates asecond user associated with the second client device.
 36. The system ofclaim 35, wherein the server authorizes the second user of the secondclient device to receive the notification including the link.
 37. Thesystem of claim 32, wherein the server generating the placeholder when asize of the at least one data file to be shared is larger than a presetsize.
 38. The system of claim 32, wherein the server generates metadatathat is descriptive of the notification and the at least one data file,and generates a meta-file based on the generated metadata, wherein themeta-file includes the at least one data file and the metadata.
 39. Thesystem of claim 38, wherein the server assigns a unique identifier tothe meta-file, wherein the unique identifier is associated with the atleast one data file for tracking purposes.
 40. The system of claim 38,wherein the metadata includes information to control, by the server, atleast one from the group consisting of: replication, transmission,access, and lifecycle management of the at least one data file.
 41. Thesystem of claim 32, wherein the second client device receives thenotification including the link and receives a selection of the link,wherein the server locates the at least one data file corresponding tothe received link at the storage device communicatively coupled to theserver, and wherein the server transmits the located at least one datafile to the second client device.
 42. The system of claim 41, whereinthe server receives an authorization key from the second client deviceand transmits the located at least one data file to the second clientdevice based on the receipt of the authorization key.